Vehicle telematics is the technology of sending, receiving and storing information to and from vehicles and is generally present (at least to a limited extent) in the automotive marketplace today. For example, both General Motors (through their OnStar offering) and Mercedes Benz (through their Tele-Aid and more recent mbrace system offering) have long offered connected-vehicle functionality to their customers. Both of these offerings make use of the data available on a vehicle's CAN bus, which is specified in the OBD-II vehicle diagnostics standard. For example, the deployment of an airbag, which suggests that the vehicle has been involved in a crash, may be detected by monitoring the CAN bus. In this event, a digital wireless telephony module that is embedded in the vehicle and connected to the vehicle's audio system (i.e., having voice connectivity) can initiate a phone call to a telematics service provider (TSP) to “report” the crash. Vehicle location may also be provided to the TSP using the vehicle's GPS functionality. Once the call is established, the TSP representative may attempt to communicate with the vehicle driver, using the vehicle's audio system, to assess the severity of the situation. Assistance may thus be dispatched by the TSP representative to the vehicle as appropriate.
Historically, these services were focused entirely on driver and passenger safety. These types of services have expanded since their initial roll-out, however, and now offer additional features to the driver, such as concierge services. The services, however, remain mainly focused on voice based driver to call center communication, with data services being only slowly introduced, hindered by low bandwidth communication modules, high cost and only partial availability on some model lines.
As a result, while generally functional, vehicle telematics services have experienced only limited commercial acceptance in the marketplace. There are several reasons for this. In addition to low speeds and bandwidth, most vehicle drivers (perhaps excluding the premium automotive market niche) are reluctant to pay extra for vehicle telematics services, either in the form of an upfront payment (i.e., more expensive vehicle) or a recurring (monthly/yearly) service fee. Moreover, from the vehicle manufacturer's perspective, the services require additional hardware to be embedded into the vehicle, resulting in extra costs on the order of $250 to $350 or more per vehicle which cannot be recouped. Thus, manufacturers have been slow to fully commit to or invest in the provision of vehicle telematics equipment in all vehicles.
There have been rudimentary attempts in the past to determine when a smartphone is in a moving vehicle. Wireless service provider AT&T, Sprint and Verizon, for example, offer a smartphone application that reacts in a specific manner to incoming text messages and voice calls when a phone is in what AT&T calls DriveMode™. With the AT&T DriveMode application, a wireless telephone is considered to be in “drive mode” when one of two conditions are met. First, the smartphone operator can manually turn on the application, i.e., she “tells” the application to enter drive mode. Alternatively, when the DriveMode application is in automatic on/off mode and the smartphone GPS sensor senses that the smartphone is travelling at greater than 25 miles per hour, the GPS sensor so informs the DriveMode application, the DriveMode application concludes that the smartphone is in a moving vehicle, and drive mode is entered.
Both of these paths to engaging the AT&T DriveMode application—the “manual” approach to entering drive mode and the “automatic” approach to entering drive mode—are problematic. First, if the smartphone operator forgets or simply chooses not to launch the DriveMode application prior to driving the vehicle when the application is in manual mode then the application will not launch. Second, in automatic on/off mode AT&T's use of only the GPS sensor to determine when a smartphone is in a moving vehicle is problematic for a number of reasons. First, the speed threshold of the application is arbitrary, meaning that drive mode will not be detected/engaged at less than 25 mph. If the vehicle is stopped in traffic or at a traffic signal, for example, then the DriveMode application may inadvertently terminate. Second, and perhaps more importantly, AT&T's DriveMode application requires that the smartphone's GPS functionality be turned on at all times. Because the use of a smartphone's GPS sensor is extremely demanding to the battery resources of a smartphone, this requirement severely undermines the usefulness of AT&T's application. Thirdly this method does not differentiate between the type of vehicle that the phone is in, e.g. a bus, a taxi or a train and therefore allows no correlation between the owner of the phone and her driving situation. For the classic embedded telematics devices to be replaces by smartphones it is important to correlate the driver and smartphone owner with her personal vehicle. Only then the smartphone can truly take the functional role of an embedded telematics device in a vehicle.
The main justification premise for a connected embedded device is the ability to not only detect an accident, but to autonomously call for help to either a privately operated emergency response center or 911. In fact, this safety function has been the main driver behind the last fifteen years of installing embedded communication devices in vehicles through major vehicle manufacturers. What is needed is a delivery of such a safety functionality without the need for any embedded device, thus allowing millions of drivers the safety benefit of automatic crash notification without the need for an expensive embedded device and a costly subscription. What is needed is an improved method and apparatus of determining, via a communication device, whether a vehicle has crashed.